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WO 01/16845 PCT/USOQ/24004 
METHOD AND APPARATUS FOR NETWORK-BASED AUTOMATED 
INSURANCE TRANSACTION PROCESSING 



Background of the Invention 

5 The present invention relates to the field of computer and network based business 

application systems, and specifically to systems which relate to the presentation, processing, and 
maintenance of insurance products and related transactions over a distributed computer system. 

Traditionally, insurance companies have utilized paper intensive systems for the 
presentation, processing, and maintenance of insurance policies to potential clients. 

1 0 Additionally, claims processing and monetary transactions, such as bill payment or payment 
under a claim, have been accomplished largely by paper means. To initiate a policy, clients 
typically have had the choice of dealing directly with an insurance company's agent and, 
typically, being limited to that company's policy choices or dealing with an independent 
insurance agent, who may offer policy choices from a group of insurance companies. In either 

1 5 case, the process of comparing, selecting, and processing a policy is largely accomplished by a 
variety of intermediate entities using largely paper processing, and to a lesser degree some 
computer processing. Additionally, because the processing of a client's policy, once selected, is 
extremely time consuming, often about six weeks, the insurance agent is only able to provide a 
policy quote, rather than an accurate premium (or price) to the client at the time the application 

20 for insurance is taken. In some systems, despite some automation, a client is tentatively issued a 
policy, which is then subject to subsequent approval and possible cancellation if certain 
underwriting rules are not satisfied. 

A typical process 100 for processing a client's policy selection is shown in Figure 1 . 
Initially, a client meets with an agent to compare policies and policy options for a specific type of 

25 insurance policy, e.g., home or auto. Based on the information provided by a client for the 

specific type of policy, the agent generates a set of comparative price quotes, shown in step 102. 
These quotes may be generated from company hard-copy literature or from tables stored in a 
computer, wherein the agents computer configuration is often highly customized with special 
software to access and use insurance company information - which may not actually be current 

30 when used. As an example, a client may inquire about an auto insurance policy including 

comprehensive coverage. The client may then request different policy price quotes for the auto 
policy having different options (or elements) selected for comparison, such as having a $500 
versus a $1 ,000 deductible option or having a towing option added to the policy. Additionally, 



1 



WO 01/16845 PCT/US00/24004 

the premium of the policy depends on unique client information, such as driving record and the 

value of the auto to be insured, and unique insurance company information, such as current 
policy rates. 

The need to process the insurance application through underwriting, including the need to 
5 verify a variety of factors involved in accurately determining a policy premium, makes it 
impossible for the insurance agent to produce a definite premium at the time the policy 
application is taken. Therefore, the agent can, at best, only provide the client with a price quote 
or quotes, which are merely estimates. Such a system and process results in the client having to 
leave the application process without having certain premium information. Therefore, the client 
10 bears an undesirable cost risk that the policy may ultimately be more costly than envisioned, 
assuming it actually issues after the underwriting process is complete. 

Once the client has selected a given policy, including any desired policy options, the 
agent prepares and submits a policy application to the insurance company (or carrier), shown in 
steps 104 and 106, and accepts a down-payment from the client. The insurance company's mail- 
1 5 room logs in the receipt of the policy application, step 108, forwards the policy application to the 
underwriting department, step 1 10, and forwards the client's down-payment to the company's 
billing department, step 109, where it is held until a decision regarding the issuance of the policy 
is made by underwriting. Among other things, the underwriting department verifies certain 
critical information in and related to the application. For example, the underwriting department 
20 may verify a client's driving record 1 12. credit history 1 14, and criminal record 1 16, along with 
applying the most current set of available underwriting rules of the company 1 18 to the 
application. The nature of such inquiries is that the data used, whether client related or insurance 
company related, may noi necessarily be current, i.e. the data may be "stale". And, even if 
current, may become stale between the time of inquiry and the time of policy issuance. In such 
25 cases, the insurance company unavoidably assumes the risk that the factors used as the basis for 
issuing a policy are correct and that these factors do not change between the time of making the 
inquiries and the time of issuing the policy. Based on the results of these types of inquiries and 
analysis, a determination is made regarding whether a policy will issue, step 120 (i.e., meets the 
underwriting guidelines). If the policy issues, step 122, it is mailed to the insurance agent, step 
30 1 24, who then notifies the client of the issuance of the policy. 

Once a policy issues, a legal notice is issued to that effect, step 126, and a bill reflecting 
the final premium is generated. Typically, the insurance company's billing department credits 
the client's original down-payment toward the premium. If the amount of the premium is less 

2 
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than the down-payment, then a refund for the difference is mailed to the insured client, in step 

132. However, it is more typical that after application of the down-payment, a balance remains 
and the insured client is billed in accordance with agreed upon billing terms reflected in the 
policy, step 130. From thereon, the insurance company generates a billing schedule and mails a 

5 bill statement to the client and the client returns statement with the appropriate payment. This 
process continues until the premium and any associated finance charges are paid in full. 

In the case where the policy application does not meet underwriting guidelines, the 
underwriting department rejects the policy application, step 134, and notifies the insurance agent, 
step 136. The agent then works with the client to replace the policy application with a revised 

1 0 application, step 1 38, that overcomes (if possible) the basis for rejection of the previous policy 
application, and in doing so returns to the initial step 102 of generating new quotes based on 
various policy changes. This process may be repeated until the agent and client finally arrive at a 
policy application that results in an issued policy by the underwriting department, if possible. 
While policies are often written to retroactively provide coverage back to the date of the 

1 5 application, such protection is only useful to the client in the case where the policy issues. If the 
policy does not issue, the client has unknowingly been uninsured between the time of application 
and the time of rejection. 

Therefore, it would be advantageous to the client to have a system which allows for 
comparison of a variety of insurance products having a variety of selected options at one time 

20 and for immediate generation and receipt of accurate price quote information for such policies. 
Furthermore, a system which provides near-real time policy issuance would eliminate any 
significant gap in coverage between the time the client applies for a policy and the time the client 
is informed as to whether the policy has been approved for issuance. Also, a system which 
allows insurance companies to efficiently maintain and control the underwriting guidelines, 

25 algorithms, rate tables, account information and other pertinent information which is accessible 
by agents, without a high degree of computer customization required by the agents, would 
expedite the policy application and evaluation process, while also reducing risk to the carrier 
associated with reliance on stale data. 

Accordingly, it is an object of the present invention to provide a highly automated 

30 distributed computer system for dynamically accepting user information and, based thereon, 
generating unique product candidate solutions, displaying said candidate solutions, accepting 
selection of one of said candidate solutions, and storing said solution. It is also an object to 
provide computer access to third party financial institutions to allow electronic transfer of funds 
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and credit card payments, for example, to facilitate bill and claim related payments. It is a 

farther object of the invention to provide access to third party information providers (e.g., motor 
vehicle, claim, and credit databases), where available, to facilitate a more efficient underwriting 
process, for example. In such a system, it is a further object to allow real or near real-time 
5 updates of product information. 

Summary of the Invention 

The present invention is a data driven automated insurance transaction processing system 
operating over a distributed communication network to provide real or near real-time generation 

10 of policy price quotes, underwriting and policy issuance, and generation of billing schedules. An 
insurance agent can login to the system over the network and gain access to a core set of engines 
(the "Core") and Framework databases, including databases containing a plurality of insurance 
provider's (or carrier's) information, and quickly provide a comparison of candidate policies and 
corresponding price quotes from among those carriers to a client. The client and agent may 

1 5 select a preferred policy from among the candidate policies and in response the system issues the 
selected policy and generates a corresponding billing schedule. Payments against the policy 
premium can be made electronically by credit and debit card, payroll deduction, or electronic 
funds transfer. Additionally, insurance claims may be filed over the network, and a claims 
adjuster and an examiner may be automatically assigned from a database of preferred adjusters 

20 and examiners. The system may also be configured to generate candidate policies of types other 
than that requested, using at least some of the client information provided. 

The system architecture includes a user management subsystem and the Framework 
database system (and its Core set of engines). Among other things, the Framework database 
system includes at least one static database for storing standard procedures, rules, and rate 

25 products and at least one dynamic database for storing data produced during a particular user 
session. The Core includes interfaces to related third party service providers (e.g., credit card 
and third party information source companies). The user management subsystem includes a 
group of software applications which may be configured for different types of users and that 
interface with the Core via the World Wide Web ("Web"), for example. As discussed below, 

30 some types of users may access the Core using a standard Web browser, while other types of 
users require a client-side application to be resident in their computer. Depending on the login 
privileges of a user, the substantive interface to the Core will vary. An interface is primarily 
created by the presentation of screen images on a workstation or terminal display. For example, 

4 
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a carriers application interface allows an insurance provider to access the Core and view their 

customers' accounts. An agent's application interface allows access to the Core for generating a 
client's profile information and accessing insurance carrier's databases and algorithms for 
generating policy rate quotes, selecting a policy, issuing a policy, generating a bill schedule, 

5 accepting premium payments and filing claims. A claims application interface allows access to 
the Core by claim examiner's and adjusters for processing claims, including reviewing a claim, 
tracking the claim, and issuing claim pay-outs to service provider's (e.g., repair shops) and to 
clients. A general developer's (or implementor's) system (i.e., a client-server application) 
includes several development tools that allow access to the Core databases for the creation and 

1 0 maintenance of the Core and related applications. Using the development tools, a rating analyst, 
for example, may create and/or enter the Web User Interface (WU1) screens, rating tables, 
algorithms, underwriting rules, associate carrier/product information with territories, generate 
help text, and enter accident and violation information on a company/product basis. Access to 
the Core is also provided for the determination of agent's commissions and for generating system 

1 5 reports. 

The Core includes an application interface server which acts as the interface between the 
Core and the management system. In the preferred embodiment, the application server is a WUI 
server that generally manages access to other servers and databases within the Framework to 
accomplish tasks requested by the external users. An underwriting engine within the Core 

20 accesses an underwriting rules database and applies these rules, as part of calculating a rate quote 
for a candidate policy, to input client profile information to determine whether or not the policy 
can be issued. If a candidate policy or policies satisfy the underwriting rules, a rate/quote engine 
within the Core generates a price quote for each candidate policy. A reporting engine is also part 
of the Core and generates reports concerning various system aspects and carrier based 

25 information for different users, as appropriate. Once a policy has been issued, a billing engine 
within the Core generates a billing schedule, issues bills and invoices, and applies payments 
received to existing accounts. At the center of the Core is a transaction engine which controls the 
general tasking within the Core and which processes premium transactions and payments 
transactions. Premium transactions relate to creating, modifying, renewing, canceling, or 

30 processing claims for an existing policy. Payment transactions relate to the transfer of money. 



Brief Description of the Drawings 

The foregoing and other objects of this invention, the various features thereof, as well as 

5 
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the invention itself, may be more fully understood from the following description, when read 

together with the accompanying drawings, as described below. 

FIGURE 1 is a flowchart of a typical prior art process for processing an insurance policy 
application. 

5 FIGURE 2 A is a block diagram of an insurance processing system and FIGURE 2B is a 

block diagram that includes the portions of the Framework and Core, in accordance with the 
present invention. 

FIGURE 2C is a diagram of a set of development tools included in the implementor's 
system of FIGURE 2 A. 

10 FIGURE 3 is a diagram of a representative page displayed at a user's workstation and 

produced by the Core of the insurance processing system of Figure 2A. 

FIGURE 4 is a table depicting a representative group of transactions performed by the 
transaction engine of the insurance processing system of Figure 2 A. 

Figures 5A - 5F are a series of tables which illustrate how a quote is achieved by the 
1 5 insurance processing system of Figure 2A. 

FIGURE 6 is a diagram of a computer architecture embodying the insurance processing 
system of Figure 2A. 

For the most part, and as will be apparent when referring to the figures, when an item is 
used unchanged in more than one figure, it is identified by the same alphanumeric reference 
20 indicator in all figures. 

Detailed Description of the Preferred Embodiments 

The present invention is a data driven automated insurance transaction processing system 
operating over a distributed communication network to, among other things, provide real or near 

25 real-time generation of policy rate (i.e., price) quotes from a variety of insurance carriers' (i.e., 
providers or companies) multiple lines of business, issue insurance policies, and generate billing 
schedules. The system includes capabilities to determine and present insurance policy 
information from one or more of a variety of sources to facilitate comparison and selection by an 
insurance agent ("agent") and/or a client, based on client profile information or data which 

30 describes relevant characteristics of the person or property to be insured. Additionally, the 
insurance processing system includes capabilities which facilitate efficient processing of an 
insured client's (the "insured's") claims. Using a compliment of automated processing and 
electronic data storage and transfer features embodied within the system, the present invention 
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allows for the paperless generation, comparison, and issuance of an insurance policy, as well as 

the electronic transfer of funds necessary for the payment of insurance premiums by the insured 
or the payment of claims by the insurance carrier. To accomplish this, the present invention 
provides real-time access to various external underwriting data sources, interfaces to outside 

5 services, such as policy printing and bank and credit card company systems, and is electronically 
coupled to various carrier systems. 

The insurance transaction processing system is designed to allow a developer (e.g., a 
rating analyst or specialist) to accomplish the generation and maintenance of, for example, rate 
quote products using a set of user friendly (i.e., non-technical) development tools. Rating 

10 analysts are individuals knowledgeable in insurance rate subject matter, and are not required to 
be skilled in computer programming. Rate quote products are used, typically by an insurance 
agent, with specific client data to generate rate quotes for that client. The ease of use of the 
system provides the ability to rapidly develop and maintain a large number of rate quote 
products, spanning multiple lines of business, and covering all states. 

15 In the preferred embodiment, the distributed communication network is the Internet and 

World Wide Web (i.e., the "Web") and the insurance processing system is a "Web-based" 
insurance processing system. In an alternate embodiment, the distributed communication 
network includes an extra-net (i.e., a form of wide area network (WAN)) using Web browser 
interfaces. Operating applications of the system, which implement relevant processes, and rate 

20 quotes produced by the system are delivered to users through a TCP/IP connection and a 
standard Web browser on the user's workstation. Delivering its services over the Web, the 
present invention generally minimizes costs, for example costs associated with the development 
and maintenance of the client-side workstation configuration. 

To facilitate automated processing, the capabilities of the system are embodied in a 

25 combination of computer software and hardware. The system architecture implemented in the 
preferred embodiment includes a variety of terminals or workstations which run or access 
applications which then provide access to a Web User Interface (" WUI") Server, an 
implementor's system including a set of development tools for product development and 
maintenance and a corresponding tools server, a plurality of third party interfaces, and a database 

30 system that provides the underlining system functionality, referred to as the "Framework". For 
the most part, the Framework database system drives system processes. For example, the 
Framework database system contains the information required to build the user interface screens, 
maintains state in the Web-based applications, stores all of the business and underwriting rules. 
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drives external processes which interface with remote systems, and stores business rule and 

transactional data. Each data element, whether a rule, a rate factor, a screen display element or 
some other data element is tagged with an effective and an expiration date, which allows each of 
the periodic rate and rule changes to be specifically preserved in the system at all times. Entering 
the appropriate policy effective date allows the corresponding rate, rule, and/or screen set to be 
automatically accessed at any time. 

The Framework is driven by and includes a standard set of stored procedures that provide 
core, data driven functionality, referred to as "the Core". The primary functional areas of the 
Framework are built as a series of Core "engines" and servers. As will be described in more 
detail and as shown in Figure 2A, the Web-based insurance processing system 200 includes a 
user management system 220 that interfaces with Core 230, wherein the Core also includes an 
interface to third party entities 250 and to a developer's/maintainer's, or implementor's, system 
260. The user management system 220 includes a variety of computer terminals or workstations 
that have access to Core 230 for transaction processing. The workstations may be remote to each 
other and to the Core, wherein communication among the various workstations and the Core 
takes place over the Web using standard communication links (e.g., phone lines). While the 
preferred embodiment uses the Internet and Web as a communication medium, other types of 
networks, such as an Intranet, extra-net, local area network (LAN), WAN or a combination of 
networks could also be used. A workstation may be any commercially available desktop 
computer running a standard operating system and Web browser (e.g., Internet Explorer™ by 
Microsoft Corporation). As such, the workstations do not require any significant customization 
to access the Core. 

The WUI server 232, which is an application server, is the primary interface between 
each workstation and the servers and engines of the Core 230 and the Framework databases they 
access. The WUI server 232 may be any commercially available server configured to 
communicate across the Internet and Web with the workstations. The engines provide the 
primary processing capability of the system 200, and include the necessary logic and hardware to 
accomplish relevant insurance processing related tasks by acting on both transactional and 
business rule data stored in dynamic and static Framework databases, respectively. Data which 
identifies the client and/or item to be insured, along with any other required client specific 
information required by the system 200, is referred to as client profile information or data, which 
is supplied by user input at a workstation during a session and constitutes at least a portion of the 
transactional data stored in a dynamic database. Data related to a specific policy, either an issued 

8 
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or candidate policy, is referred to as policy data and includes client profile information as 

necessary, and also constitutes at least a portion of transactional data. 

A simplified database structure is shown in Figure 2B, those skilled in the art will 

appreciate that the databases may or may not be physically co-located with the engines or with 

5 each other and may be distributed over several devices and backed-up and mirrored as desired. 
Because the system is both an insurance transaction processing system and a development 
system (used for, among other things, maintenance and updates), the Framework database system 
225 design is easily extensible by using commonly available and standard devices and interfaces. 
Extensibility is also accomplished in large part through the use of vertical "objectized" data 

10 structures. That is, when new data elements are required, they are added as a row in a data 

element master table, not as columns in a hard-coded table structure. Data element properties are 
stored in related tables and may be configured by product, carrier, or user, for example. The 
database structure is discussed further below and with respect to Figures 2B and 6. 
I. Management System (Workstations) 

1 5 There are several types of users which may access the Core to perform, in most cases, a 

subset of available system functions. For example, typical users may include insurance agents, 
clients, insurance carriers, claims adjusters and examiners, and system developers and 
maintainers (e.g., a "rating analyst"). In the preferred embodiment, different types of users have 
different privileges. For example, insurance carrier rating analysts have privileges to create and 

20 update rate tables and underwriting rules within the Core, but clients may only have privileges to 
review an existing policy and account information, and agents may only have privileges to 
generate, renew, and review a policy. Consequently, the system 200 includes user specific 
application interfaces (i.e., computer screens and functionality) rendered on workstations 202 - 
212. Some of these application interfaces merely require a standard Web browser to access the 

25 Core, while others require user specific client-side applications. These application interfaces 
allow predetermined types of access to Core 230, each interface having functions specific to its 
corresponding type of user, based on predetermined user privileges. These workstations and 
interfaces are collectively referred to as the user management system 220. The Web browser 
application interfaces are actually generated by the Core and communicated to the workstations 

30 as hypertext markup language (HTML) code and then rendered on the workstation within a Web 
browser. 

In Figure 2A ? a group of representative user specific "applications", each running on a 
standard workstation, is shown as a simplified depiction of the preferred embodiment. However, 
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in practice, a plurality of workstations running the same application, for example, a plurality of 

workstations at different locations running agent's application 205, is more likely to be the case. 
Additionally, each workstation may run more than one type of application, such flexibility being 
a function of the login privileges of different types of users (e.g., carriers, agents, and claims 

5 adjusters), and wherein such users may login to and access the Core from any Web enabled 
workstation. As a general notion, types of users and access privileges may be defined in a 
variety of ways, as is known in the art. In the preferred embodiment, communication between 
the Core and each workstation takes place over the Web (and Internet) using commercially 
available hardware and software interfaces, systems and communication links (e.g., phone lines). 

10 Each type of user specific application included in management system 220 is described more 
folly below. 

Referring once again to Figure 2A, a claims application 202 allows a claim examiner and 
adjuster to access the Core and manage the processing of insurance claims via a Web browser. 
Claim information may initially be entered into the Core via an agent's (or carrier's) workstation 

1 5 and an examiner and adjuster may be automatically assigned to the particular claim or 

recommended from a Core database of preferred examiners and adjusters. An examiner or 
adjuster may update and manipulate claim data from a workstation running claims application 
202 during the course of claim resolution. Other users may also take part in updating or 
providing claim related data, such as an agent or carrier. Furthermore, an adjuster may facilitate 

20 payment of a claim electronically by transferring funds from the carrier's bank to the insured's 
bank or to the bank of a service provider. A service provider may be any entity involved in the 
repair, replacement, or resolution of the subject matter of the claim, such as an auto repair person 
or shop. 

A carrier's application 204 is a compliment of carrier screens and functionality displayed 
25 and available within the Web browser of a workstation and which allows a carrier to access the 
Core directly for carrier specific purposes. The carrier's application 204 provides access to the 
Core to allow the carrier to update carrier information, such as rate tables and underwriting rules 
stored in the static Framework database 255. The carrier's application 204 also allows the carrier 
to access and manipulate existing policy and account information (stored in the long term 
30 database 265), accomplish payment transactions, generate new policies, and so on. 

An agent's application 205 is a compliment of screens and functionality displayed and 
available within the Web browser of a workstation to allow an insurance agent to generate price 
quotes, have policies issued, query existing policies, and process claims, for example. In 

10 
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practice, the actual privileges associated with an agent's workstation may vary depending on a 

variety of factors. For example, it may be the case where an agent may only be authorized to sell 
products from a certain carrier or carriers, while other agents may be authorized to sell products 
offered by any available carriers. It is envisioned that workstations or terminals running the 

5 agent application will be located at various locations where agents service the needs of existing 
and potential clients. For example, access to the system of the present invention may be 
franchised to agents and agencies, wherein agent workstations may be located in any of a variety 
of locations as franchise locations. Such locations may include traditional agency offices or non- 
traditional forums such as retail store or wholesale club locations, as a means of improving the 

1 0 consumer's accessibility to such insurance related services and products. 

A data access application 206 is a compliment of screens and functionality displayed and 
available as a client-side application running on a workstation that is used for accessing and 
extracting data from and storing data to the management system 220. The data access 
application 206 may be used by any of a variety of users to obtain reports and data consistent 

15 with the user's privileges. For instance, data (e.g., system performance measures) may be 
extracted from the Framework database system by a system manager using the data access 
application 206 to determine if system performance is acceptable. 

A system manager's application 208 is used to generally maintain the Core 230, e.g., keep 
applications, frameworks, utility versions, and so on up to date via a Web browser. The system 

20 manager can monitor system performance and tune the system by adjusting, to some degree, the 
allocation of system resources (e.g., processors and memory). 

A commissions application 210 is a compliment of functionality and screens accessible 
on a workstation that is interfaced with a call center and agency application 212 to accomplish 
up-to-date commission processing and maintenance of commission rates within the a carrier's 

25 call center or an agency. The call center and agency application 212 logs on to the Core to 
retrieve information related to the determination of an insurance agent's earned commissions, 
such information being maintained within the Core as part of typical transaction processing. 
II. The Core 230 

The Framework database system provides the primary functionality and data storage 
30 capability of the preferred embodiment of the present invention, and it is the Core 230 of the 

Framework which provides the functionality, as shown in Figure 2B. Core 230 accesses a series 
of Framework databases which store data, such as business and underwriting rules for each 
insurance carrier (in database 255), client policy and account information (in database 245 and/or 

11 
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265), and all other necessary business and transactional data. In the preferred embodiment, the 

Framework databases are object-centric relational Structured Query Language (SQL) databases, 
version 6.5. SQL databases are known in the art and are not discussed in detail herein. For the 
most part, Core 230 includes a series of stored procedures that provide data-driven functionality, 

5 referred to as "engines" and servers. As examples, the engines and servers use the data in the 
Framework databases to build user interface screens, generate policy information and quotes, 
issue, store and maintain policies, and accomplish claims processing. These engines and servers 
include: billing engine, rate/quote engine, reporting engine, tools server, transaction engine, 
underwriting engine, and WUI server. Generally, the servers provide interfaces between external 

10 users and the Core and the engines accomplish tasks in response to server requests. The Core 
includes external interfaces to the management system workstations and to third party systems 
for performing a variety of ancillary insurance transaction functions, such as electronic funds 
transfer, credit/debit card authorizations and transactions, and lock box processing. Core 230 
also includes an interface to implementor's system 260, which includes a set of development 

1 5 tools for the creation of WUI pages, rate tables, underwriting rule databases and so on, as well as 
general maintenance of the system. Each engine and server is described below, 
a. WUI Server 232 

The WUI server 232 is the primary interface of external users to the Core for processing 
insurance transactions. In the preferred embodiment each WUI server is a commercially 

20 available server running Windows NT™ Server 4.0 software, by Microsoft Corporation. The 
WUI server 232 includes functionality which generates and communicates, in real-time, HTML 
computer screen information corresponding to a screen image to be rendered at a user T s 
workstation during a session. When the HTML screen information is received, the user's 
workstation processes the information using a standard Web browser to produce and present the 

25 desired screen image. As the interface to the workstations of the management system 220, the 
WUI server controls user privileges, as a function of the user's login, for accessing the Core. 

More specifically, the WUI server 232 extracts rules from the Framework databases, as 
shown in Figure 2B, guiding which graphic, data, and functional elements are to be displayed 
then dynamically builds pages according to a predefined general layout. As a result, system 

30 performance is enhanced, wherein the WUI server 232 generates screen information dynamically 
in response to user inputs, such that the next screen to be displayed is a function of the client 
profile information and responses input in the current (and previous) screens, as well as the 
business and underwriting rules stored within the Framework databases. Building screens 

12 
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dynamically involves generating and sending software code from the WUI server 232 to a 

workstation, wherein the Web browser running on the workstation compiles the code (e.g., 

HTML code) and builds the screen therefrom. The preferred embodiment employs software 

written using a commercially available server-side scripting software language, such as 

ColdFusion® (by Allaire™ Corporation), to accomplish the dynamic generation of screen 

images processed and displayed by the Web browser, using data from the Framework databases. 

Therefore, once the user submits responses to the WUI server 232 (via a workstation) the server 

executes the server-side scripting language (which is an application) to quickly generate HTML 

code, which is then sent by the WUI server back to the workstation and Web browser of the user. 

The Web browser running on the workstation then builds the appropriate screen using the 

HTML code. 

To start a session, a user logs on to WUI server 232 via the Web using the standard Web 
browser interface. The user may, for example, be an agent working with a client to obtain policy 
information and compare policies or a user may be a client seeking to review the status of an 
existing policy. In other embodiments, the client may be given the flexibility to compare and 
have policies issued without the use of an agent. Using agent's workstation 205 and WUI server 
232 generated screens, the user enters client profile information (or client data) to define the 
client and/or property to be insured to the system 200 and to identify the type of policy or 
policies of interest, which is stored in transactional database 245 during the agent's/client's 
session. Client data identifies the client and subject matter of the policy of interest and includes, 
for example, the client's name, age, and address, and also includes any basic information 
necessary for the system to generate one or more policy rate quotes for the type of policy of 
interest. For example, this basic information may include the make, model, and year of an 
automobile to be insured. In addition to generating computer screen information, the WUI server 
232 manages the flow of information in and out of the Core, and (along with the transaction 
engine 236) the assignment of tasks to engines and the storing of data into Framework databases. 

Through the WUI server 232, users remotely perform a variety of transactions, such as 
obtain policy rate quotes, access billing information, and process claims. To facilitate the input 
of relevant information for processing a transaction, the WUI server 232 incorporates a 4-Ievel 
hierarchical tree structure within the screen images, including pages 300, sections 305, questions 
310, and options 3 15 (the lowest level), as shown in Figure 3. That is, a page contains sections, 
sections contain questions, and questions contain options. As an example, page 300 in Figure 3 
relates to an automobile policy and the input of client profile information. A page is an 

13 
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electronic graphical equivalent (i.e., screen image) of a physical page of data. A section 305 

divides a page 300 into sets of questions 3 1 0. A question 3 1 0 solicits a response and, thereby, 
obtains information for the Core transaction processing. A question may be visible or hidden, 
wherein a visible question may ask for date of birth and the hidden question may compute age 
5 therefrom. For the most part, responses to questions are stored in dynamic transactional database 
245. 

Each question is assigned a data type to define the form of the response, which 
corresponds to a data definition within a Framework database. In the preferred form, data types 
include free text, drop-down list, and button. A data type of free text relates to a question that 

1 0 requires a free text response typed into a corresponding answer field. A data type of drop down 
list means that the question requires the response be selected from a corresponding list of 
responses (i.e., options 315). A data type of button refers to a question that is displayed as either 
a button or hyperlink, which when clicked submits a request for a new page to the Web browser. 
Questions may also include formulas, typically embodied within the servers and engines, that 

1 5 aid in the generation of the code corresponding to the next page to be submitted to the 

workstation. For example, if a user selects the option "Under 25 years of age", then the code 
generated for the next page submitted will be different than if the user selected the option "Over 
25 years of age". Those skilled in the art will appreciate that other forms of input data types may 
be used, such as graphical sliding scales, audio/voice data input, and so on, without departing 

20 from the present invention. 

In practice, once the user has logged into the Web server 232, the Web browser running 
on the remote user's workstation submits a request for a page to the WUI server 232. The WUI 
232 server analyzes the request and returns the appropriate screen image code and data to the 
workstation, assuming the request is consistent with the user's privileges. The WUI server 232 

25 passes user requests and associated tasking to the transaction engine 234 (as shown in Figures 2 A 
and 2B), which then tasks the other Core engines and servers to accomplish tasks related to the 
user's request, some of which may involve the Core obtaining information from third parties. For 
example, if a user is seeking to obtain rate quotes for a new auto insurance policy in 
Massachusetts, Core 230 may be configured to automatically request the client's driving record 

30 from the Massachusetts Registry of Motor Vehicles, assuming it is available on-line, and such 
information may be used in determining whether the client is insurable and, if so, comparative 
policy rate quotes are generated, 
b. Transaction Engine 234 

14 
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The transaction engine 234 receives user transaction requests via the WU1 server 232 and 

serves as the central director and manager for processing within Core system 230, as shown in 
Figures 2 A and 2B. In response to workstation requests by a user, the WUI server 232 passes the 
user's request to the transaction engine 234 for processing. The transaction engine then controls 
5 the processing of the transaction using the other engines and servers within the Core 230 and 
Framework databases as needed. In the preferred embodiment, transactions primarily fall into 
one of two groups, either premium transactions or payment transactions. Premium transactions 
potentially effect the policy premium. The types of transactions in the premium transaction 
group include: new business (i.e., policies) and policy amendments, changes, endorsements, 

10 renewals, cancellations, rescissions, terminations, non-renewals, and claims processing. 

Payment transactions involve the transfer or exchange of money, and the group includes billing 
termination and resumption, premium returns, receipt of payments (including cash), transfers of 
funds electronically, and write-offs. A representative list of actions (i.e., transactions) and 
descriptions preformed by the transaction engine 234 in the preferred embodiment is provided in 

1 5 Figure 4. Generally, each type of transaction is customary in the insurance business and will not 
be explained in detail herein and, in fact, most are self-explanatory. 

The transaction engine 234 includes three managers, which are embodied in stored 
procedures and data (associated with, for example, rating server 630a of Figure 6) used for 
processing transactions, and serves as the central processor of the WUI server 232 requests. As 

20 such, the transaction engine 234 interacts with other severs and engines within the Core and 

Framework databases, as required. The transaction engine 234 includes a transaction manager, a 
quote manager, and a policy manager, in the preferred embodiment. Generally, the managers 
respond to user manipulation of a WUI screen (e.g., answering questions) at the user's 
workstation to create, modify, or view a policy, for example. As part of a user's request, the 

25 WUI Server 232 assigns a value ("Q" for quote or "P" for policy) to a "transaction type" 

parameter associated with the user's request. The WUI server 232 calls transaction engine 234 
which invokes the transaction manager to service the user's request for a transaction, using 
procedures, rules, and rate products in database 255. In the preferred form and as shown in 
Figure 2B ? the standard procedures, rules, and rate products are stored in substantially static 

30 database 255 and transactional data (e.g., client profile data and rate quotes) associated with a 

particular user's session are stored in a dynamic (or relatively temporary) database 245. It should 
be understood that databases 255 and 265 are not truly static, in that they are updated from time 
to time, for example, when a carrier issues new rate products. However, with respect to the 
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session oriented dynamic database 245, databases 255 and 265 are relatively static. 

Based on the value of the transaction type parameter, the transaction manager directs the 
request to either the quote manager or the policy manager. If the user has requested comparative 
policy rate quotes the transaction type parameter is set to "Q" and the transaction manager 
invokes the quote manager to operate on the request by interacting with the rate/quote engine 
236. The quote manager saves information from the front-end (i.e., workstation) to a quote 
repository in dynamic database 245 for use by the rate/quote engine and retrieves information 
from the repository for use by the front-end. Once the rates are determined by the rate/quote 
engine, the quote information is passed from the rate/quote engine 236 to the billing engine 242 
(but staying within database 245), where a billing schedule is automatically generated. 

If the quote type parameter is set to "P" and a policy already exists, the transaction 
manager invokes the policy manager to retrieve the requested policy and, subsequently, desired 
policy actions (e.g., renew) may be accomplished. On the other hand, if the quote type parameter 
is set to "P" and a policy does not exist, the transaction manager invokes the policy manger to 
create a new policy image into which the client profile data is merged, and processing is passed 
to the rate/quote engine 336 for generation of a rate quote, which is stored in transactional 
database 245 until the policy is issued or the session is ended, 
c. Rate/ Quote Engine 236 

The rate/quote engine 236 provides the client and agent with a quote, or bottom-line 
price, for an insurance product or products. The rate/quote engine is a set of back-end procedures 
and tables in static database 255 that perform mathematical calculations. The engine 236 
matches rating elements with client profile information in dynamic database 245 to calculate 
"components", which are the building blocks of a quote. Premiums are calculated for each 
component and the sum of all premiums is presented as the quote. For the most part, there are 
three parts to the rate/quote engine 236: client profile information, rate product algorithms, and 
quotes. Client profile information (i.e., client data) is information stored in database 245 about 
the client that is entered at a workstation into the WUI server 232 by the user, as discussed 
previously. The rate product algorithms are stored in database 255 and used to calculate rate 
quotes, each carrier may have their own algorithms and each policy type and policy option 
offered by each carrier may have a unique set of algorithms. A quote is the policy cost at a given 
point in time. And, rating elements are carrier defined rates for individual coverages. 

A component is the mathematical representation of a coverage, which, when combined 
with other components, comprises the total premium. For any component, there can also be sub- 
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components. For an item to be a component of a coverage or total premium, it must be 

computed before the coverage or total premium is computed. While components are 
mathematical expressions, formulas determine the amounts that comprise the components. Since 
the determination of one component may be used to determine another component, components 

5 are processed in a deliberate order, referred to as the "rate sequence." 

To understand how components and a rate are calculated, it is useful to know how carrier 
manual details (rates, algorithms, etc.) are mapped to formulas and components. As an example, 
Figure 5A shows a table of the bodily injury (BI) rating elements listed in an insurance manual 
for a hypothetical carrier XYZ. BI is just one of the numerous rating elements that make up the 

1 0 total premium. The left column (a through k) lists the elements that make up the BI rating 
component. The right column (A through J) lists the component calculations (or formulas). 
With the above information, a tree-diagram is created which represents how the rating elements 
are to be processed. This tree is created by starting at the first element to be processed (i.e., Base 
Rate x Territory Relativity) and diagramming the components until the last element is included. 

1 5 Figure 5B shows the resulting tree-diagram 5 1 0. Once the tree-diagram 5 1 0 has been created, 
the rating elements can be entered into the system, applying formulas to components and 
assigning rate sequences. 

A rate sequence is a number assigned to each element and represents the order in which 
elements are processed in order to calculate the total premium. For example, if there are two 

20 components, Territory Relativity and Multi-car Discount Factor, and the Multi-car Discount 
Factor needs to be multiplied by a number that includes Territory Relativity in its formula, 
Territory Relativity will have a lower rate sequence than Multi-car Discount Factor. In this case, 
the rate sequence assigned to the Base Rate times Territory Relativity is 70, and the sequence 
assigned to Multi-car Discount Factor is 35. This way, the components that make up the Multi- 

25 car Discount multiplier (which includes Territory Relativity) can be processed first. It is 

preferable to have a unique rating sequence for each component, but the rate sequence number 
need not be unique. For example, two unrelated questions, both with a rate sequence of 70, will 
be processed in an arbitrary order as determined by the system immediately after questions with 
rate sequences of less than 70. 

30 The rate/quote engine inverts the tree-diagram of Figure 5B, as shown in Figure 5C, and 

starts processing at the lowest level of the tree. In this example, components with rate sequence 
60 are the individual coverage premiums. Components with rate sequence 70 are the sums of 
these premiums and many other factors that may be applied (e.g., car rental factor). Rate 
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sequence 80 sums all the components, resulting in the total premium. 

Components are calculated using rates and factors, which are based on coverage choices 
and associated limits and the client profile information. Figure 5D shows the base rate and the 
factors for the BI coverage, as defined by the hypothetical carrier XYZ. The base rate is 
5 dependent on Territory and other similar client-related information. To illustrate how rating is 
done, the BI premium is calculated, as an example, using a specific hypothetical client profile. In 
this example the client profile information is such that the client: 



I) always uses his car, and 
j) will pay semi-annually. 

Figure 5E shows how the rates are assigned to this client profile for the BI coverage. The 
factors are calculated and shown in Figure 5F, wherein the total BI premium is $853. This 

20 premium is ultimately added to the premiums for other coverages (not shown), resulting in the 
total policy premium. In this example, there is one car and one driver. If a policy has multiple 
cars and/or drivers, the rate/quote engine will process a component calculation for each. 

A temporary Framework database location, i.e., dynamic database 245, holds each 
premium, that is each component calculation. The premiums for each component are summed to 

25 produce the total policy premium. The total policy premium is the quote, before issuance. In the 
preferred embodiment, two tables (i.e., databases) are populated when the actual rate/quote 
transaction occurs, a premium table and a question table. The premium table is where premium 
information is stored for each component calculation and includes effective and expiration date 
tags, since a rate quote will only be valid for a fixed amount of time typically. Ultimately, the 

30 question table is used to save the answers associated with each component; this table stores the 
information used to obtain the quote. A policy (or total premium) quote is based on client profile 
information and the business climate at a specific moment in time. If the quote is accepted by 
the client, it is stored in permanent database 265 and made into a policy. If the quote is not 
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a) chooses 25/50 BI coverage, 

b) lives in territory 5, 

c) is thirty -five years of age 

d) drives a car for pleasure (non-business), 

e) has one Driving Under the Influence conviction and one violation, 

f) would like to increase his limit factor, 

g) owns one car that is rated as having "intermediate" performance, 

h) also has a homeowner's policy, 
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accepted, it may be saved in temporary database 245. In a comparative rating environment, there 

may be many quotes from multiple carriers stored. 

The system may be configured to generate candidate or recommended policies of types 
in addition to the policy type for which the initial quotes were sought. In such a case, it would be 

5 preferable, but not essential, that the system generate such candidate policies and quotes based 
solely on the client profile information input to obtain the initial quotes. As an example, if a 
client and agent requested quotes for an automobile policy, the system can search the Framework 
databases to determine whether the client has an existing homeowner's policy and, if not, the 
system generates and offers comparative homeowner's quotes to the client, in addition to the auto 

10 quotes. 

d. Underwriting Engine 238 

Generally speaking, underwriting is the process in which a carrier assesses the risks of 
insuring the client and determines whether to offer insurance based on that assessment. 
Underwriting rules exist in an underwriting rules database of the Framework for each type of 

15 policy offered by each carrier, such as database 255. The underwriting engine 238 and rules are 
accessed by the rate/quote engine 236 in response to a request for a rate quote, such information 
and rules being used to facilitate the generation of a rate quote for a given carrier. In the 
preferred form, the rate/quote engine 236 tasks the underwriting engine 238 to apply rules before 
a quote is actually calculated. That is, once it is clear that the carrier would underwrite the 

20 candidate policy, the rate quote is prepared and initially stored in transactional database 245. 

e. Tools Server 240 

The key to developing applications with the system is a development tool set included as 
part of the implementor's system 260. The development tool set shields an application developer 
from the underlying table structures and stored procedures of the system and provides a user 

25 friendly, rapid development environment for building and maintaining rate quote products. For 
the most part, tools server 240 is accessed and used by the implementor's system 260 as an 
interface to Core 230. The tools server 240 is, therefore, a development and maintenance server 
which includes the functionality to process inputs from a developer or maintainer (e.g., rating 
analyst) to create and edit WUI pages, sections, etc. and to create carrier products (e.g., rate quote 

30 products). 

f. Billing Engine 242 

The billing engine 242 generates a billing schedule, that is, a schedule of payments, 
issues bills and invoices, and applies payments. The billing engine 242 accesses third party 
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financial institutions to accomplish any of a variety of monetary transactions, as appropriate. 

Monetary transaction methods include, for example, payroll deductions, electronic funds 
transfers, and credit/debit card transactions, 
g. Reporting Engine 244 

The reporting engine provides carriers, agents, and system managers with reports on 
various aspects of the system through the various applications. Such reports generally provide 
business management information. For example, the following reports are provided to the 
following types of users: 

a) to carriers: new business, renewals, written/earned premium, claims etc.; 

b) to agents: those of part a) above plus commissions; 
and c) to system managers: same as part b). 

III. Other Interfaces 

a. Implementor's System 260 

The implementor's system 260 is used by developers (e.g., rating analysts) to create and 
maintain rating products (see Figures 2 A, 2B, 2C and 6) stored in the static Framework database 
255 and used by the Core's rate/quote engine 236. The implementor's system 260 includes 
several development tools (or tool modules), shown in Figure 2C, in the preferred embodiment, 
which are stored in static database 255. These development tools include a web user interface 
tool 261 that is used to design and layout WUI screens or pages, such as the computer display 
screens accessed by an agent when requesting an insurance policy rate quote from the system 
200. Such screens include information and questions which prompt the agent to enter client 
profile information required to provide a policy rate quote. A rating tool 262 is used to enter 
basic rates into rate tables and to enter and store rate algorithms and procedures. These rates, 
algorithms and procedures are associated with rating questions, which ultimately are presented to 
a user in WUI pages, wherein the responses are used for determining the final rate quotes. Each 
carrier determines their own rates and algorithms and those are built into Core 230 using the 
rating tool 262. An underwriting tool 263 is used to enter carrier specific underwriting rules as 
logical formulas into static Framework database 255. A territory tool 264 is used to enter the 
specific territories and corresponding rate factors used by the rating engine, per company and per 
product. Accordingly, territory codes are associated with ZIP codes corresponding to the 
geographic area or areas for which insurance coverage can be obtained. Generally, a rate quote is 
a function of the rates, algorithms, and rate factors for the geographic area or territory in which 
the policy is to be issued. For example, a carrier's basic rate for a certain policy may be $100 
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which then gets multiplied by a factor of 1.1 for a given geographic territory to produce a final 

rate quote of $110. 

The ability to generate useful quotes is, of course, dependent on the sufficiency and 
accuracy of the user's inputs. Therefore, a question help tool 266 is used by the rating analyst to 

5 enter help text for each question to be included in the WUI screen displays. A violations tool 
267 is used for auto, motorcycle, and boat rate products, to specify the accidents and violations 
that the insurance carrier tracks for the purpose of rating each insured driver/operator. In the 
preferred embodiment, a specific violation code (SVC) mapping tool 268 is used to map standard 
violation codes, accessed via ChoicePoint Inc., to company specific violation codes for auto, 

10 motorcycle and boat rate products. An unacceptable vehicle tool 269 allows a rating analyst to 
specify the make and model of each vehicle that each insurance carrier does not insure for auto, 
motorcycle, and boat rate products. The information entered via tools 267-269 is also used in 
calculating rates, for the appropriate types of policies. 

As will be appreciated by those skilled in the art, various development tools may be 

1 5 defined which embody the basic functionality (or modifications thereto) of the development tools 
described herein without departing from the spirit and scope of the present invention. The tools 
described herein are intended to be illustrative and not exhaustive, 
b. 3 rd Party Interfaces 250 

Third party interfaces 250 include interfaces to a variety of entities and services useful in 

20 automating the transaction processing of the insurance processing system 200. More 

specifically, the third party interfaces are responsible for retrieving underwriting verification data 
from industry specific service bureaus, transferring policy data to carriers, and importing data to 
system Framework databases from carriers for the purpose of billing and claims inquiry. Such 
third parties also include banks (as shown in Figure 6) and credit card companies, as well as 

25 other financial institutions, accessed for electronic fund transfers, payroll deductions, credit card 
charges and so on to pay premiums and other insurance related expenses or to issue refunds or 
pay outs. Third parties may also provide financial information. For example, the system may 
interface with First Data, Inc. for real-time credit card authorizations. As another example, the 
system may include interfaces to state or federal agencies having information relevant to the 

30 insurability of a client, perhaps criminal or motor vehicle database information. One example of 
a commercially available database interfaced by the preferred embodiment of the insurance 
transaction processing system 200 is provided by ChoicePoint, Inc., which provides real-time 
access to motor vehicle registry data for about thirty states, presently, and also provides credit 
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history as well as claim history information for automobiles and personal property. Another 

database interfaced by the system is made available by Trans Union Inc., which provides 
individuals 1 credit scores. To obtain such data, the WUI server of the present invention provides 
a "COM" object over the network to relevant third parties, wherein the object includes built-in 
5 methods used to request information from the data and service providers to which they link. It is 
envisioned that such third party information would become increasingly available and that the 
present invention incorporates interfaces to such increasingly available databases and sources. 
IV. Architecture 

Figure 6 shows a preferred architecture 600 which implements the insurance processing 

10 system 200 shown in Figures 2 A and 2B. The server topology is configured as two networks. A 
first network 605 is routed to external networks for user access, and a second network 61 0 is a 
non-routed internal network for database access. The front-end WUI servers 232a-c are multi- 
homed with one network interface to the routed network 605, and a second network interface to 
the non-routed, back-end SQL server network 610. All Framework data are maintained in back- 

1 5 end dedicated SQL servers 620 and 630a-b that are single-homed, not routed. The third party 
interface server 650 runs system custom software to access 3 rd party data sources 655 linked to 
the database network 610. 

The front-end WUI servers may be duplicated as required for scalability, and are 
clustered for high availability, preferably using a "cluster CATS" solution from Allaire, Inc.. 

20 The back-end SQL servers are also clustered and all systems run with mirrored hot swapable 

drives and redundant power supplies, for high availability and fault protection. The Framework 
includes a collection of individual SQL server databases that may be run on multiple separate 
computers, as load balancing demands. Load is distributed among these sources based on user 
logon and therefore may be grouped in logical units, such as all agents in one or more states. 

25 The databases shown in Figure 6 depict a physical implementation of the static and dynamic 
databases of Figure 2B. Wherein, temporary databases 624, 636a and 636b correspond to 
dynamic database 245 of Figure 2B and the remaining databases of Figure 6 correspond to static 
databases 255 and 265 of Figure 2B. 

With more specific regard to the preferred embodiment shown in Figure 6, each WUI 

30 server 232a-c is actually a cluster of individual servers, with each WUI server supporting one 
database server. Generally, each WUI server cluster is paired with a database server and 
typically designated for a specific type of user, but this need not always be the case. For 
example, WUI server cluster 232a is designated for general management application serving, that 
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is, it is not designated to any specific type of user (see discussion related to workstations 202, 

204, and 208 in Figure 2A). WUI server 232b is designated for call center rating and WUI server 
232c is designated for agency rating (see discussion related to workstations 210 and 212 in 
Figure 2A). Those skilled in the art will realize that either more or less WUI servers 232 could 
5 be included in the architecture 600 and dedicated to one or more sub-groups of users in a variety 
of configurations. 

A plurality of rate product servers 630a-b are included within the architecture and are 
accessed by their associated WUI servers 232a-b respectively. While only two rate product (i.e., 
"QUOTE Services") servers are shown in Figure 6, there can be any number of rate product 

10 servers, wherein a rate product server can be associated with a given state, carrier, or line of 
business. Each rate product server 630a and 630b includes a corresponding general database 
management Framework 632a and 632b, respectively, including a series of general utilities and 
information 634a and 634b used by the server to assist in the generation of rate quotes. Also 
included with each server as part of the Framework is a temporary data storage area 636a and 

15 636b, each of which is used as a repository for data while the rate quote is being prepared. 

Information that may be stored in such an area includes client profile information and candidate 
policy information. Once a candidate policy is chosen (i.e., a preferred policy) and a policy is 
issued, that policy is stored in a permanent (or long term) memory location, such as database 265 
of Figure 2B. 

20 The architecture of Figure 6 also includes a report application server 640 which hosts a 

variety of applications for producing reports used in the general monitoring and maintenance of 
the system and for analyzing carrier and agent related information including client account 
information. Additionally, there is a third party interface server 650 which is used, for example, 
by the billing engine 242 and underwriting engine 238 of the Core. As an example, the billing 

25 engine may use the third party interface server to exchange information necessary to conduct 

electronic fund transfers with a bank or between banks 655, or among other financial institutions. 
The third party interface 650 is also used to access data from information providers during the 
underwriting and rate quote process to verify or obtain client profile information, depending on 
the availability of on-line resources. 

30 The system is maintained on a single set of servers, preferably, and delivered via an IP 

connection and a browser. Consequently, maintenance and software version control is greatly 
simplified. For example, when a carrier issues a modified set of rates or underwriting rules, the 
new rates are entered into the system "development" area, then moved to a "staging area" for 
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Quality Assurance (QA) review, and ultimately released to the production servers where they 

then become available for use by agents, clients, and so on. The development area refers to an 
off-line development environment where manipulation, formatting, and testing of code is 
accomplished, as needed, using system tools as preparation for releasing the new rates and/or 
rules as software code to the production system 200. Once the development team is satisfied that 
such code is ready for release, the code is moved to the staging area which models the production 
system, and QA provides verification of the code's readiness. Because a single set of servers is 
used, release to production by QA accomplishes a simultaneous upgrade for all users. 
Additionally, the reliance on commonly available and standard computers and interfaces (e.g., 
Windows NT servers, SQL server databases, Web browser interfaces, and so on) and the ability 
to seamlessly add additional servers to support additional users results in an architecture with 
relatively unlimited scalability. 

The invention may be embodied in other specific forms without departing from the spirit 
or central characteristics thereof. The present embodiments are therefore to be considered in all 
respects as illustrative and not restrictive, the scope of the invention being indicated by 
appending claims rather than by the foregoing description, and all changes that come within the 
meaning and range of equivalency of the claims are therefore intended to be embraced therein. 
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1 1 . An insurance transaction system for processing transactions related to new or existing 

2 insurance policies across a remote communication network by a user, the insurance 

3 transaction system comprising: 

4 A. at least one computer workstation having a display screen and an input device, by 

5 which the user interacts with said insurance transaction system; 

6 B. at least one database having insurance rating information and underwriting rules 

7 stored therein for a plurality of insurance carriers; 

8 C. an application server, including: 

9 I. an application interface, which generates initial and subsequent prompts at 

I o said workstation for the user to input client data associated with a specific 

I I client, wherein said subsequent prompts are dynamically generated as a 

1 2 function of previous client data inputs at said workstation; 

13 ii. a quote generator which, as a function of said client data inputs, said rating 

14 information, and said underwriting rules, generates data representations, 

1 5 including rate quotes, of one or more candidate policies of a selected 

1 6 insurance product type from the plurality of insurance carriers; 

1 7 iii. a display generator which displays at the display screen said candidate 

1 8 policies for comparison, if more than one candidate policy has been 

1 9 generated by said quote generator, and selection of a preferred policy from 

20 said one or more candidate policies by said user using the input device; 

21 iv. a policy issuer which, as a function of the user's selection of a preferred 

22 policy, establishes in said database an issued policy corresponding to said 

23 preferred policy and correlated to said client; and 

24 v. a billing generator which generates and stores in said database an 

25 electronic billing schedule corresponding to said issued policy; and 

26 d. a communication network which interconnects said workstation with said 

27 application server and said database. 

1 2. The insurance transaction system of claim 1 wherein the database includes rating 

2 information and underwriting rules for at least one other type of insurance product and 

3 the quote generator includes a companion quote generator which, as a function of said 
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4 client data inputs and said rating information and underwriting rules for at least one other 

5 type of insurance product, generates data representations of one or more candidate 

6 companion policies from the plurality of carriers. 

1 3. The insurance transaction system of claim 1 wherein the communication network 

2 includes the Internet. 

1 4. The insurance transaction system of claim 1 wherein the communication network 

2 includes the World Wide Web. 

1 5. The insurance transaction system of claim 1 wherein the communication network 

2 includes at least an extra-net or an intra-net. 

1 6. The insurance transaction system of claim 1 , wherein the application server further 

2 includes: 

3 vi. a payment processor which accepts electronic funds transfer information 

4 input at said workstation, including a payment amount to be transferred 

5 from an identified financial account associated with said client and client 

6 policy identification information which identifies a policy to which the 

7 payment is to be applied; and 

8 vii. a bill updater which applies the payment amount to a balance of the 

9 identified policy and recalculates the balance and generates a revised 

10 billing schedule as a function of the application of said payment amount. 

1 7. The insurance transaction system of claim 6, wherein the said electronic funds transfer is 

2 of the type from the group comprising payroll deduction, direct payment, and electronic 

3 bill payment. 

1 8. The insurance transaction system of claim 1 , wherein the application server further 

2 includes: 

3 vi. a payment processor which accepts credit card information input at said 

4 workstation, including a payment amount to be credited from an identified 

5 credit card account associated with said client and client policy 
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6 identification information which identifies the policy to which the 

7 payment is to be applied; and 

8 vii. a bill updater which applies the payment amount to a balance of the 

9 identified policy and recalculates the balance and generates a revised 

10 billing schedule as a function of the application of said payment amount. 

1 9. The insurance transaction system of claim 1 , wherein a subset of said underwriting rules 

2 and rating information residing on said database relates to each carrier, and said subset is 

3 accessible and maintainable independently by the carrier to which the subset corresponds 

4 and across the computer network. 

1 10. The insurance transaction system of claim 1 , wherein the system is adapted for the 

2 processing of an insurance claim in accordance with a client's existing policy issued by an 

3 insurance carrier and stored in said database, wherein a subject matter of said claim 

4 identifies the situation to be remedied or damage to be repaired under said claim, and the 

5 database includes information corresponding to a set of preferred providers for providing 

6 services related to remedying said situation or repairing said damage and a set of 

7 insurance adjusters for assessing the monetary claim value associated with said remedy or 

8 repair under said policy, wherein the application server includes: 

9 vi. a claims input interface, which generates prompts at said workstation for 

1 0 the input of client claim data, including the subject matter of said claim 

1 1 and identification of the client's existing policy in said database; 

12 vii. an adjuster assigner, which assigns an insurance adjuster to said claim, the 

1 3 assignment being a function of a set of predefined adjuster criteria stored 

1 4 in said database and said claim data; and 

1 5 viii. a provider assigner, which assigns at least one preferred provider from said 

16 set of preferred providers to said claim, the assignment being a function of 

17 a set of predefined provider criteria stored in said database and said claim 

18 data. 

1 11. The insurance transaction system of claim 1 0, wherein the application server further 

2 includes: 

3 ix. a claim payment processor which electronically transfers a payment 
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4 amount derived from said claim value from a carrier financial account of 

5 said insurance carrier to a preferred provider financial account of said 

6 preferred provider. 

1 12. The insurance transaction processing system of claim 1, further including: 

2 e. a framework database system which includes said at least one database as a 

3 substantially static database. 

1 13. The insurance transaction processing system of claim 12, wherein said framework 

2 database system includes objectized extensible databases. 

1 14. The insurance transaction processing system of claim 12, wherein said framework 

2 database system includes at least one dynamic database for storage of transactional data, 

3 said transactional data including session oriented data comprising at least said client data 

4 and said candidate policies. 

1 15. The insurance transaction system of Claim 1 , further including an implementor's system 

2 comprised of a workstation and a plurality of development tools usable to create at least a 

3 portion of said application interface and to enter and store in said database said insurance 

4 rating information and underwriting rules from a graphical user interface, wherein each 

5 development tool includes program code stored and executable on said workstation. 

1 1 6. The insurance transaction system of claim 1 5, wherein said application interface is 

2 comprised of a plurality of display screens and said development tools include a web user 

3 interface tool configured to layout said display screens and generate corresponding 

4 program code and wherein said display screens include said application interface initial 

5 and subsequent prompts. 

1 1 7. The insurance transaction system of claim 1 6 wherein the display screens are pages which 

2 are segmented into one or more sections, and wherein each section may include one or 

3 more questions and each question may include one or more options. 



1 



1 8. The insurance transaction system of claim 17, wherein said development tools include a 
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2 question help tool configured to enter and associate with each question explanatory help 

3 text to facilitate a user's accurate input of said client data. 

1 19. The insurance transaction system of claim 1 5, wherein said rating information includes 

2 rates, rate formulas, and rate procedures and said development tools include a rating tool 

3 configured to enter and store in said database, for each product or policy of each 

4 insurance carrier, said rates, rate formulas, and rate procedures and selectively create 

5 associations between at least a portion of said rating information and said application 

6 interface initial and subsequent prompts. 

1 20. The insurance transaction system of claim 1 5, wherein said development tools include an 

2 underwriting tool configured to enter and store in said database, for a given carrier, said 

3 underwriting rules as logical formulas. 

1 21. The insurance transaction system of claim 1 5, wherein said development tools include a 

2 territory tool configured to associate one or more pre-existing insurance carrier territory 

3 codes, as part of said rating information, with one or more geographic Zip codes, wherein 

4 a territory code is indicative of the degree of risk associated with offering a given policy 

5 in a given geographical area. 

1 22. The insurance transaction system of claim 1 5, wherein said development tools include a 

2 violations tool configured, for auto, motorcycle, or boat insurance policies offered by a 

3 given carrier, to define and enter into the insurance transaction system one or more types 

4 of accidents and violations tracked by said carrier for the purpose of generating said rate 

5 quotes. 

1 23. The insurance transaction system of claim 1 5 wherein said insurance transaction system 

2 is capable of accessing, via said communication network, a third party violations database 

3 system having predetermined third party violation codes, and said development tools 

4 include a specific violation code mapping tool configured to map said third party 

5 violation codes to carrier specific violation codes in said database, for auto, motorcycle, 

6 or boat insurance policies offered by each carrier. 
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1 24. The insurance transaction system of claim 1 5, wherein said development tools include an 

2 unacceptable vehicles tool configured to define, as part of said rating information, for 

3 each insurance carrier, the make and model of each auto, motorcycle, and boat not 

4 insurable by said insurance carrier, for each auto, motorcycle, or boat insurance policies 

5 offered by said insurance carrier. 

1 25. A method for processing insurance transactions within an insurance transaction system 

2 having at least one workstation including a display screen and an input device, at least 

3 one database, and at least one application server interconnected via a communications 

4 network, wherein the database includes rating information and underwriting rules from a 

5 plurality of insurance carriers, the method including the steps of: 

6 A. prompting a user to select at said workstation a type of transaction from among a 

7 plurality of available transaction types, including: 

8 i. issuing a new policy, wherein a plurality of candidate policies are 

9 generated and displayed for selection of a preferred policy by the user; 

1 0 ii. effecting a payment related to a policy; and 

1 1 iii. processing a claim against an existing policy; 

12 B. prompting the user to input at said workstation client data required by the 

1 3 insurance transaction system for the processing of the selected type of transaction, 

1 4 wherein subsequent prompts are dynamically generated as a function of the 

1 5 previously input client data; and 

16 C. processing said selected transaction as a function of said client data and rating 

17 information. 

1 26. The method for processing insurance transactions of claim 25 wherein, when the selected 

2 type of transaction involves issuing a new policy of a selected insurance product type, 

3 step C includes: 

4 C-l . generating, as a function of said user inputs, rating information, and 

5 underwriting rules, data representations, including rate quotes, of one or 

6 more candidate policies from the plurality of carriers; 

7 C-2. displaying at said display screen the candidate policies for comparison, if 

8 more than one candidate policy has been generated, and selection of a 

9 preferred policy from said one or more candidate policies by said user 
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1 0 using said input device; 

1 1 C-3. establishing in said database, as a function of the user's selection of said 

1 2 preferred policy, an issued policy corresponding to said preferred policy 

1 3 and correlated with said client; and 

1 4 C-4. generating and storing in said database an electronic billing schedule 

1 5 corresponding to said issued policy. 

1 27. The method for processing insurance transactions of claim 25, wherein the database 

2 includes rating information and underwriting rules for at least one other type of insurance 

3 product, and step C further includes: 

4 C-l . 1 . generating data representations of candidate companion policies 

5 from the plurality of carriers, as a function of said client data inputs 

6 and said rating information and underwriting rules, for at least one 

7 other type of insurance product. 

1 28. The method for processing insurance transactions of claim 25, wherein said workstation 

2 communicates with said application server via the Internet. 

1 29. The method for processing insurance transactions of claim 25, wherein said workstation 

2 communicates with said application server via the World Wide Web. 

1 30. The method for processing insurance transactions of claim 25 wherein said workstation 

2 communicates with said application server via at least an extra-net or an intra-net. 

1 31. The method for processing insurance transactions of claim 25, wherein when the selected 

2 type of transaction involves effecting a payment, the step C includes: 

3 C- 1 . inputting at said workstation electronic funds transfer information, 

4 including a payment amount to be transferred from an identified financial 

5 account associated with said client and client policy identification 

6 information which identifies a policy in said database having a balance to 

7 which the payment is to be applied; 

8 C-2 . applying said payment by electronically transferring said payment amount 

9 from said identified financial account to a carrier financial account 
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1 0 associated with said policy; and 

1 1 C-3. recalculating said balance and generating a revised billing schedule as a 

1 2 function of the application of said payment. 

1 32. The insurance transaction system of claim 31 , wherein electronically transferring said 

2 payment constitutes a transaction of the type from the group comprised of payroll 

3 deduction, direct payment, and electronic bill payment. 

1 33. The method for processing insurance transactions of claim 25, wherein when the selected 

2 type of transaction is effecting a payment, step C includes: 

3 C-l . inputting at said workstation credit card information, including a payment 

4 amount to be credited from an identified credit card account associated 

5 with said client and client policy identification information which 

6 identifies a policy in said database having a balance to which the payment 

7 is to be applied; 

8 C-2. applying said payment by electronically crediting said payment amount to 

9 said identified credit card account and transferring said payment amount to 

10 a carrier financial account associated with said policy; and 

1 1 C-3. recalculating said balance and generating a revised billing schedule as a 

12 function of the application of said payment. 

1 34. The method for processing insurance transactions of claim 25, wherein a subset of said 

2 rating information and said underwriting rules in said database corresponds to a first 

3 carrier from said plurality of carriers, the method further including: 

4 D. accessing remotely over the communication network said database by a first 

5 carrier; and 

6 E. updating said corresponding subset of rating information and underwriting rules 

7 in said database by said first carrier. 

1 35. The method for processing insurance transactions of claim 25, wherein when the selected 

2 type of transaction involves processing an insurance claim in accordance with an existing 

3 policy issued by an insurance carrier and stored in said database, a subject matter of said 

4 claim identifies the situation to be remedied or damage to be repaired under said claim, 
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5 and the database further includes information corresponding to a set of preferred 

6 providers for providing services related to remedying said situation or repairing said 

7 damage and a set of insurance adjusters for assessing the monetary claim value associated 

8 with said remedy or repair under said policy, step B includes: 

9 B-l . inputting at said workstation client claim data, including the subject matter 

10 of said claim and identification of the client's existing policy; and 

1 1 step C includes: 

12 C-l . generating and displaying at said workstation a preferred adjuster list from 

1 3 said set of preferred adjusters as a function of a set of predefined adjuster 

14 criteria and said claim data; 

1 5 C-2. generating and displaying at said workstation a preferred provider list from 

1 6 said set of preferred providers to said claim as a function of a set of 

1 7 predefined provider criteria and said claim data; and 

1 8 C-3. assigning, based on client selection at said workstation, at least one 

19 preferred adjuster from said preferred adjuster list and at least one 

20 preferred provider from said preferred provider list.. 

1 36. The method for processing insurance transactions of claim 35, wherein step C further 

2 includes: 

3 C-4. electronically transferring an amount derived from said claim value from a 

4 carrier financial account of said insurance carrier to a preferred provider 

5 financial account of said preferred provider. 

1 37. A method of conducting insurance related transactions over the Internet using an 

2 insurance transaction system, each transaction being part of a session related to a specific 

3 client being serviced by an insurance agent using a workstation, having Internet access, to 

4 input client data and otherwise interact with said insurance transaction system, wherein 

5 said insurance transaction system includes: 

6 i. a framework database system which includes and manages at least one 

7 dynamic database for storing session oriented data and at least one static 

8 database for storing at least a set of standard procedures, underwriting 

9 rules, and insurance carrier rate products; and 

10 ii. a core set of engines and servers, wherein said engines accomplish the 
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1 1 processing of said insurance transactions using the data in said framework 

12 database system and wherein at least one server provides an interface 

1 3 between the Internet and said engines; and 

14 wherein said method includes the steps of: 

1 5 A. populating said static databases with said standard procedures, underwriting rules, 

1 6 and rate products for each of a plurality of insurance carriers; 

17 B. selectively designating, within said framework database system, at least one 

18 insurance agent having access and privileges to said insurance transaction system 

19 for processing insurance related transactions; and 

20 C. accessing said insurance transaction system with said workstation and via the 

21 Internet by said insurance agent, inputting said client data, and selectively 

22 processing an insurance related transaction by accessing said core set of engines 

23 and servers. 

1 38. The method of conducting insurance related transactions of claim 37, wherein said agent 

2 is a franchisee located in a wholesale club. 

1 39. The method of conducting insurance related transactions of claim 37, wherein said 

2 insurance related transactions include generating a plurality of candidate policies and 

3 corresponding rate quotes for a client as a function of client data input by said agent at 

4 said workstation and related to said client and said standard procedures, underwriting 

5 rules, and rate products. 

1 40. The method of conducting insurance related transactions of claim 39, wherein said 

2 insurance related transaction includes issuing a preferred policy, selected from said 

3 plurality of candidate policies, and associating said preferred policy with said client in 

4 said framework database management system, and generating a billing schedule 

5 associated with said preferred policy. 



34 



WO 01/16845 



PCMJS00/24004 



1 41 . The method of conducting insurance related transactions of claim 40, wherein said 

2 insurance related transaction includes accomplishing a payment of at least a portion of a 

3 premium associated with said preferred policy, including electronically transferring a 

4 payment amount from an account associated with said client to an account associated 

5 with a carrier of said preferred policy. 

1 42. The method of conducting insurance related transactions of claim 37, wherein said client 

2 data, said plurality of candidate policies, and said rate quotes are session oriented data 

3 stored in said dynamic database. 

1 43. The method of conducting insurance related transactions of claim 37, wherein said 

2 insurance related transactions include processing an insurance claim by said agent as a 

3 function of said input client data and an existing insurance policy issued to said client and 

4 providing coverage for said claim, wherein an adjuster for evaluating a monetary claim 

5 value associated with resolving said claim is chosen from a preferred adjuster database in 

6 said framework database system and a service provider for resolving said claim is chosen 

7 from a preferred provider database within said framework database system. 
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Action 


Description 


Bind 


Invoked when the Insurance Center creates a policy that contains temporary 
billing information. (Policy status is Bind). 


CAN 


Cancel Flat - invoiced when the policy is cancelled on renewal (e.g. the insured 
changes carriers on renewal). 


CLA 


Cancel Lost Account - invoked when a client changes agencies or carriers. 


CRW 


Cancel Rewrite - invoked when a policy is cancelled due to non-payment, or 
when the insured chooses a new carrier. 


CTE 


Cancel Terminate - invoked when the insured is a member of a group 
(typically an employer group) which terminates its relationship with the 
insurance carrier. 


Endorsement 


Invoked when the insured purchases coverages typically excluded from the 
terms of the policy. 


Generate 


Generates a billing schedule for a new policy. 


Issue 


Invoked when the insured purchases a new policy. A down payment had been 
made. 


List 


Lists all policies for a specific client. 


New 


Invoked when a client applies for a policy. A billing schedule is generated and 
the billing schedule status is set to active. 


Pay Bill 


Invoked when the insured pays additional cash to an agent, who at the 
insured's request, applies the additional cash to a specific bill. 


Pay Next 


Invoked when the insured pays additional cash to an agent, who at the 
insured's request applies the additional cash to the insured's next bill. 


Preview 


Invoked for a policy that contains only temporary billing information; the 
policy status is left blank. 


Rec 


Invoked when the insured pays additional cash to the agent and the agent, at 
the insured's request, applies the additional cash evenly over the remaining 
length of time of the bill. 


Rei 


Reinstate - Invoked when the insured reactivates the policy after the 
cancellation date, but prior to the five-day grace period. 


Renewal 


Invoked when an agent or Insurance Center employee wants to renew a policy. 


Rescind 


Invoked when the insured reactivates a policy prior to the cancellation date. 


Retrieve 


Invoked when an agent or Insurance Center employee wants to retrieve a 
policy for endorsement or display purposes. 


Upload 


Invoked for an account that is not billed by Insurance Center/carrier, but by a 
different Managing General Agent (MGA) who is responsible for the billing. 
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Components of BI 




Rating Element 




Calculation 


a. 


Base rate 


A. 


a x b (dollar rounded) 


b. 


Territory relativity 


B. 


A + c (if c applies, dollar rounded) 


c. 


Increased limit factor 


C. 


dxe. 


d. 


Primary class factor 


D. 


C x f (truncated to 3 decimals) 


e. 


Secondary class factor 


E. 


B x D (dollar rounded) 


f. 


Performance factor 


F. 


E x g (if g applies, dollar rounded) 


o 
&* 


Clean driver discount 


a 


F x h (if h applies, dollar rounded) 


h. 


Multi-car discount factor 


H. 


G x i (if i applies, dollar rounded) 


i. 


Auto/Home discount factor 


1. 


H x j (if j applies, dollar rounded) 


j- 


Lay-Up credit 


J. 


1 x k (dollar rounded) 


k. 


Term factor 
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Limits and Factors 


Base Rate 


Limit 


Factor 


$48.52 


20/40 


0.85 


u 


25/50 


0.90 


it 


50/100 


1.00 




100/200 


1.10 


It 


100/300 


1.15 


it 


300/300 


1.20 


It 


250/500 


1.23 


u 


300/500 


1.25 




500/500 


1.30 
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Rate Sequences 


Component 


Rate 
Sequence 


Base rate x Territory relativity = A 


10 


Primary class factor x Secondary class factor = C 


10 


A x Increased limit factor = B 


15 


C x Performance factor 


20 


BxD = E 


25 


E x Clean driver discount = F 


30 


F x Multi-car discount factor = G 


35 


G x Auto/Home factor = H 


40 


H x Lay-up credit = I 


45 


1 x Term factor = J 


60 


Perform the same component summation for Property Damage = A 1 


60 


Perform the same component summation for PIP = Bl 


60 


Perform the same component summation for PP1 - CI 


60 


Perform the same component summation for Collision = Dl 


60 


Perform the same component summation for Uninsured Motorist = El 


60 


Perform the same component summation for Towing, etc. = Fl 


60 


Add coverages A 1 + BI + CI +DI + EI + FI 


70 


Sum any other factors/credits 


70 


Sum all components to derive the total premium 


80 
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Elements 


Element 


Coverage Choice 


Rate Factor 


Base rate 


N/A 


$48.52 


Coverage factor 


25/50 


0.90 


Territory relativity 


Territory 5 


1.0949 


Primary class factor 


35 years old/pleasure 


0.90 


Secondary class factor 


I conviction point/I at-faults 


1.30 


Increased limit factor 


This is a semi-annual credit 


$12.00 


Performance factor 


Intermediate performance 


1.15 


Clean driver discount 


None, because there are accidents 


1.0 


Multi-car discount factor 


None 


1.0 


Auto/Home factor 


Has a homeowner's policy 


0.95 


Lay-up credit 


Car is always used 


1.0 


Term factor 


Semi-annual calculations apply 


1.0 
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Components 


Component 


Rate 
Sequence 


Math 


Result 


Base rate x Territory relativity = A 


10 


48.52 x 1.0949 


437 


Primary class factor x Secondary class factor = C 


10 


.9x 1.30 


1.17 


A + Increased limit factor = B 


15 


437+12 


449 


C x Performance factor = D 


20 


1.17 x 1.15 


2 


B x D = E 


25 


449x2 


898 


E x Clean driver discount = F 


30 


898 x 1 


898 


F x Multi-car discount factor "= G 


35 


898 x 1 


898 


G x Auto/Home factor = H 


40 


898X.95 


853 


H x Lay-up credit = 1 


45 


853 x 1 


853 


1 x Term factor = J 


60 


853 x 1 


853 
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